Sharing Mutable Objects and Controlling Groups of Tasks in a Concurrent and Distributed Language

This paper presents: (i) an operational semantics, based on a functional framework, for a concurrent and distributed extension of the Scheme programming language, (ii) a coherency protocol taking care of shared mutable objects, (iii) a new coherency protocol to imperatively control hierarchical groups of cooperating tasks. These two protocols do not require broadcast, nor FIFO communications, nor a centralized machine; they allow to manage an unbound number of shared mutable values and groups of tasks. This paper also advocates for the use of a functional continuation-based presentation for these protocols. The omnipresence of interconnected networks exacerbates the need for high level languages allowing to express and control widely distributed computations. Much network services such as news, finger, archie, netfind etc. ODL93] basically manage a set of informations which is accessed and enriched on a world-distributed basis. We think that it will become more and more necessary for these services as well as future ones to ooer causal coherency. In the case of the news system for instance, to receive answers before questions would not be possible. We have been designing an extension of the Scheme programming language, a Lisp dialect called Icslas, allowing to write such applications. We do not expect whole applications to be written in our language but rather wish to ooer the ideal glue to tie together sequential sub-applications. It will act as a kind of \shell" ooering high level constructs and built-in causal coherency. Therefore the Icslas language has not been designed for speed-up but for expressiveness. Being a member of the Lisp family of dialects, the Icslas language is highly dynamic and supported by a garbage collector (GC). This distributed GC is described in LQP92]. Causal coherency is usually studied independently of any language and often limits the number of shared mutable values or requires broadcast (or mul-ticast) to be achieved. Since Icslas allows to create at run-time as many shared mutable values as wanted (within memory constraints) and since communication delays through networks as well as computer failures make broadcast diicult, our coherency protocols circumvent these two problems. It is often the case that one wants to control the progress of distributed computations and possibly suspends or resumes them. The Icslas language does not